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Carnegie  Mellon 
Software  Engineering  Institute 

Purpose 

The  purpose  of  this  module  is  to  describe  the  major 
changes  to  the  CMMI  models  for  vl  .2. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Model  Changes 

The  model  was  changed  mainly  due  to  the  following: 

•  Reduce  complexity  and  size 

•  Expand  model  coverage 
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Carnegie  Mellon 
Software  Engineering  Institute 

Reduce  Complexity  and  Size 

To  reduce  model  complexity  and  size,  the  following 
changes  were  made: 

•  eliminated  advanced  practices  and  common  features 

•  eliminated  the  Supplier  Sourcing  (SS)  addition 

•  incorporated  Integrated  Supplier  Management  (ISM)  into 
Supplier  Agreement  Management  (SAM) 

•  consolidated  and  simplified  the  IPPD  material 

•  added,  modified,  and  consolidated  definitions  in  the 
glossary  (e.g.,  bidirectional  traceability,  subprocess) 

•  adopted  a  single  book  approach  (i.e.,  both 
representations  are  published  in  one  document) 
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Carnegie  Mellon 
Software  Engineering  Institute 

Expand  Model  Coverage 

To  expand  model  coverage,  the  following  changes  were 
made: 

•  added  hardware  amplifications 

•  added  two  work  environment  specific  practices  —one  in 
Organizational  Process  Definition  (OPD)  and  one  in 
Integrated  Project  Management  (IPM) 

•  updated  notes  and  examples  to  address  service 
development  and  acquisition 

•  updated  the  model  name  to  CMMI  for  Development 
(CMMI-DEV)  to  reflect  the  new  CMMI  architecture 
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Carnegie  Mellon 

Software  Engineering  Institute 

Other  Significant  Model  Changes 

Other  significant  model  changes  made  include 

•  improved  the  clarity  of  the  Overview  section  (Part  One) 

•  added  information  about  and  clarified  how  generic 
practices  (GPs)  are  used 

•  moved  the  generic  goals  and  practices  to  Part  Two 

•  explained  how  process  areas  support  the  implementation 
of  the  GPs 

•  added  GP  elaborations  for  GP  3.2 

•  restricted  the  process  areas  that  can  be  considered  “not 
applicable”  to  SAM 

•  added  emphasis  on  project  startup  in  OPF  and  IPM 
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Carnegie  Mellon 
Software  Engineering  Institute 

Advanced  Practices  Eliminated 

There  were  two  types  of  advanced  practices  in  vl  .1 : 

•  those  paired  with  a  base  practice 

•  those  that  stood  alone 

To  eliminate  advanced  practices,  the  following  strategies 
were  used: 

•  Where  a  base  and  advance  practice  covered  the  same 
topic,  the  practices  were  combined. 

•  Where  there  was  only  an  advanced  practice,  the 
advanced  practice  was  retained  as  a  specific  practice. 

•  Specific  practice  numbering  was  simplified  to  exclude  the 
capability  level. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Base  and  Advanced  Practices 
Combined 

The  following  base  and  advanced  practices  were  combined  to 
form  specific  practices  in  vl  .2. 

Requirements  Development 

•  SP  1.1:  Elicit  Needs  (combined  with  “Collect  Stakeholder 
Needs”) 

•  SP  3.5:  Validate  Requirements  (combined  with  “Validate 
Requirements  with  Comprehensive  Methods”) 

Technical  Solution 

•  SP  1.1:  Develop  Alternative  Solutions  and  Selection  Criteria 
(combined  with  “Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria”) 

•  SP  2.3:  Design  Interfaces  Using  Criteria  (combined  with 
“Establish  Interface  Descriptions”) 
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Carnegie  Mellon 
Software  Engineering  Institute 

Advanced  Practices  Converted1 

The  following  advanced  practices  were  retained  as  specific 
practices  in  vl.2. 

Requirements  Management 

•  SP  1.2:  Obtain  Commitment  to  Requirements 

•  SP  1.4:  Maintain  Bidirectional  Traceability  of 
Requirements 

Requirements  Development 

•  SP  3.4:  Analyze  Requirements  to  Achieve  Balance 
Technical  Solution 

•  SP  1 .2:  Select  Product  Component  Solutions 

•  SP  2.2:  Establish  a  Technical  Data  Package 

•  SP  2.4:  Perform  Make,  Buy,  or  Reuse  Analyses 
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Carnegie  Mellon 
Software  Engineering  Institute 

Advanced  Practices  Converted2 

Product  Integration 

•  SP  1.2:  Establish  the  Product  Integration  Environment 

•  SP  1.3:  Establish  Product  Integration  Procedures  and 
Criteria 

Verification 

•  SP  1.2:  Establish  the  Verification  Environment 

•  SP  1 .3:  Establish  Verification  Procedures  and  Criteria 

•  SP  2.3:  Analyze  Peer  Review  Data 

•  SP  3.2:  Analyze  Verification  Results 

Validation 

•  SP  1.2:  Establish  the  Validation  Environment 

•  SP  1 .3:  Establish  Validation  Procedures  and  Criteria 
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Carnegie  Mellon 
Software  Engineering  Institute 

No  More  Common  Features 

Discussion  of  common  features  was  removed  from  Part  1 . 

GPs  are  no  longer  organized  by  common  features. 

The  common  feature  headings  were  removed. 

The  generic  practices  in  vl  .2  are  presented  by  generic  goal 
and  are  sequentially  numbered. 
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Carnegie  Mellon 

Software  Engineering  Institute 


Model  Structure1 
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Carnegie  Mellon 
Software  Engineering  Institute 

No  More  Supplier  Sourcing  Addition 

Supplier  Sourcing  was  eliminated  as  an  addition. 

ISM  has  been  eliminated. 

SAM  has  been  enhanced  to  contain  the  unique  material 
from  ISM. 

Two  specific  practices  were  added  to  Goal  2  in  SAM: 

•  SP  2.2  -  Monitor  Selected  Supplier  Processes 

•  SP  2.3  -  Evaluate  Selected  Supplier  Work  Products 
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Carnegie  Mellon 
Software  Engineering  Institute 

Simplified  IPPD  Material 

There  are  no  longer  whole  process  areas  that  address 
IPPD: 

•  removed  OEI  and  moved  material  to  OPD 

•  removed  IT  and  moved  material  to  IPM 

Information  that  addressed  “Enable  IPPD  Management” 
was  moved  to  OPD. 

Information  that  addressed  “Apply  IPPD  Principles”  was 
moved  to  IPM. 

All  IPPD  material  was  condensed  and  revised  to  be  more 
consistent  with  the  other  model  material. 
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Carnegie  Mellon 
Software  Engineering  Institute 
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Carnegie  Mellon 
Software  Engineering  Institute 

The  Model  Is  a  Single  Document 

All  representations,  additions,  and  disciplines  are  in  one 
document. 

Users  can  choose  to  use: 

•  representation-specific  content  (i.e.,  continuous,  staged) 

•  addition-specific  content  (i.e.,  IPPD) 

•  amplifications  (i.e.,  hardware  engineering,  software 
engineering,  systems  engineering) 
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Carnegie  Mellon 
Software  Engineering  Institute 

Added  Hardware  Amplifications  and 
Examples 

Six  hardware  amplifications  were  created  to  add  emphasis 
on  hardware  engineering.  Here  is  an  example  from  TS. 

SP  2.1  Design  the  Product  or  Product  Component 

Develop  a  design  for  the  product  or  product  component. 

For  Hardware  Engineering 

Detailed  design  is  focused  on  product  development  of 
electronic,  mechanical,  electro-optical,  and  other  hardware 
products  and  their  components.  Electrical  schematics  and 
interconnection  diagrams  are  developed,  mechanical  and 
optical  assembly  models  are  generated,  and  fabrication  and 
assembly  processes  are  developed. 

Hardware  examples  were  also  added  to  emphasize 
hardware  engineering. 

©  2006  by  Carnegie  Mellon  University 


CMMI 


CMMI  vl.2:  Model  Changes  -  081706  -  Page  20 


Carnegie  Mellon 
Software  Engineering  Institute 

Added  Work  Environment  Coverage 

Work  environment  standards  are  established  at  the 
organizational  level  in  OPD. 

SP  1.6  Establish  Work  Environment  Standards 
Establish  and  maintain  work  environment  standards. 

The  project’s  work  environment  is  established  at  the  project 
level  in  IPM. 

SP  1 .3  Establish  the  Project’s  Work  Environment 
Establish  and  maintain  the  project’s  work  environment 
based  on  the  organization’s  work  environment  standards. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Other  Specific  Practice  Changes 

OID,  SP  1.4 

Select  process  and  technology  improvements  [not 
“improvement  proposals”]  for  deployment  across  the 
organization. 

OPP,  SP  1.1 

Select  the  processes  or  subprocesses  [not  “process 
elements”]  in  the  organization’s  set  of  standard  processes 
that  are  to  be  included  in  the  organization’s  process- 
performance  analysis. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Overview  Section  Improvements 

The  following  improvements  were  made  to  the  model 
overview  (i.e.,  Part  One): 

•  The  chapter  containing  the  generic  goals  and  practices 
was  moved  to  Part  Two  with  the  process  areas. 

•  All  definitions  are  consolidated  into  the  glossary. 

•  Chapters  were  reordered  into  a  more  logical  sequence. 

•  The  Preface  and  Using  CMMI  Models  chapter  were 
rewritten  and  updated. 

•  Descriptions  were  updated  to  reflect  the  new  CMMI 
architecture: 

-  Added  descriptions  of  constellations  and  additions 

-  Removed  descriptions  of  base  and  advanced 
practices  and  common  features 
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Carnegie  Mellon 
Software  Engineering  Institute 

Improved  Generic  Practices1 

Editorial  changes  were  made  to  the  generic  practices. 
These  slides  highlight  the  changes  that  affect  the  content. 

GP  1.1:  Perform  Specific  Practices 

The  practice  title  and  statement  changed  from  “perform 

base  practices”  to  “perform  specific  practices.” 

GP  2.2:  Plan  the  Process 

The  informative  material  was  condensed  to  be  consistent 
with  the  other  generic  practices. 

GP  2.4:  Assign  Responsibility 

In  the  informative  material  “and  authority”  was  added. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Improved  Generic  Practices2 

GP  2.6:  Manage  Configurations 

In  the  GP  statement,  “levels  of  configuration  management” 
was  changed  to  “levels  of  control.” 

GP  2.9  Objectively  Evaluate  Adherence 

Added  informative  material  to  emphasize  work  products 

also. 

GP  5.2:  Correct  Root  Causes  of  Problems 
Added  notes  that  the  focus  of  this  GP  is  on  a  quantitatively 
managed  process,  though  root  causes  may  be  found 
outside  of  that  process. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Explained  Generic  Practices  Better 

Moved  generic  goals  and  practices  to  Part  Two  with  the 
process  areas  so  that  all  normative  elements  of  the  model 
are  consolidated  in  one  place 

Added  information  about  how  process  areas  support  the 
implementation  of  generic  practices  (GPs) 

Added  GP  elaborations  for  GP  3.2 
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Carnegie  Mellon 
Software  Engineering  Institute 

“Not  Applicable”  Process  Areas 

The  set  of  PAs  evaluated  to  achieve  a  maturity  level  is  an 
important  variable  when  conducting  an  appraisal.  In  vl.1  it 
was  not  clear  which  PAs  could  be  considered  “not 
applicable.” 

In  vl  .2,  the  guidance  for  appraisals  exists  in  both 
SCAMPISM  MDD  Appendix  A  and  SCAMPI  A  Appraisal 
Disclosure  Statement  (ADS): 

•  Only  SAM  can  be  declared  not  applicable. 

•  Decisions  on  PAs  included  in  the  appraisal  must  be 
made  by  the  lead  appraiser  in  conjunction  with  the 
appraisal  sponsor. 

•  Rationale  for  declaring  SAM  to  be  “not  applicable”  must 
be  provided  in  the  Appraisal  Disclosure  Statement. 


CMMI 


©  2006  by  Carnegie  Mellon  University 


CMMI  vl.2:  Model  Changes  -  081706  -  Page  27 


Carnegie  Mellon 

Software  Engineering  Institute 

Topics 

Overview  of  Model  Changes 
Detailed  Changes 
Glossary  Changes 
Process  Area  Changes 


©  2006  by  Carnegie  Mellon  University 


CMMI 


CMMI  vl.2:  Model  Changes  -  081706  -  Page  28 


Carnegie  Mellon 
Software  Engineering  Institute 

Glossary  Changes 

The  following  slides  contain  significant  changes  to  glossary 
definitions.  Definitions  that  only  had  editorial  changes  are  not 
included. 

New  definitions:  addition,  amplification,  bidirectional  traceability, 
customer  requirement,  data,  functional  configuration  audit, 
hardware  engineering,  higher  level  management,  physical 
configuration  audit,  project  startup,  and  service. 

Revised  definitions:  acquisition,  appraisal,  appraisal  findings, 
appraisal  scope,  audit,  capability  evaluation,  configuration  audit, 
customer,  data  management,  establish  and  maintain,  generic 
goal,  objective  evidence,  process  element,  product,  product 
component,  project,  quality-  and  process-performance  objectives, 
requirements  traceability,  shared  vision,  subprocess,  traceability, 
and  work  product. 
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Carnegie  Mellon 
Software  Engineering  Institute 

Definitions  Deleted  From  the  Glossary 

Deleted  definitions:  ability  to  perform,  advanced  practices, 
agreement/contract  requirements,  appraisal  tailoring, 
appraisal  team  leader,  base  practices,  CMMI  model 
tailoring,  commitment  to  perform,  directing  implementation, 
discipline  amplification,  lead  appraiser,  process  context, 
solicitation  package,  strength,  verifying  implementation, 
weakness 

Many  of  these  definitions  were  deleted  because  the  term 
wasn’t  used  in  the  model  or  the  overall  concept  was 
removed. 
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Carnegie  Mellon 
Software  Engineering  Institute 

New  Definitions1 

addition 

In  the  CMMI  Product  Suite,  a  clearly  marked  model 
component  that  contains  information  of  interest  to  particular 
users.  In  a  CMMI  model,  all  additions  bearing  the  same 
name  (e.g.,  the  IPPD  addition)  may  be  optionally  selected 
as  a  group  for  use. 

amplification 

Amplifications  are  informative  model  components  that 
contain  information  relevant  to  a  particular  discipline.  For 
example,  to  find  an  amplification  for  software  engineering, 
you  would  look  in  the  model  for  items  labeled  “For  Software 
Engineering.”  The  same  is  true  for  other  disciplines. 
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Carnegie  Mellon 
Software  Engineering  Institute 

New  Definitions2 

bidirectional  traceability 
An  association  among  two  or  more  logical  entities  that  is 
discernable  in  either  direction  (i.e.,  to  and  from  an  entity). 
(See  also  "requirements  traceability"  and  "traceability.") 

customer  requirement 

The  result  of  eliciting,  consolidating,  and  resolving  conflicts 
among  the  needs,  expectations,  constraints,  and  interfaces 
of  the  product's  relevant  stakeholders  in  a  way  that  is 
acceptable  to  the  customer.  (See  also  “customer.”) 
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Carnegie  Mellon 
Software  Engineering  Institute 

New  Definitions3 

data 

Recorded  information,  regardless  of  the  form  or  method  of 
recording,  including  technical  data,  computer  software 
documents,  financial  information,  management  information, 
representation  of  facts,  numbers,  or  datum  of  any  nature  that 
can  be  communicated,  stored,  and  processed. 

functional  configuration  audit 

An  audit  conducted  to  verify  that  the  development  of  a 
configuration  item  has  been  completed  satisfactorily,  that  the 
item  has  achieved  the  performance  and  functional 
characteristics  specified  in  the  functional  or  allocated 
configuration  identification,  and  that  its  operational  and  support 
documents  are  complete  and  satisfactory.  (See  also 
"configuration  audit,"  "configuration  management,"  and 
"physical  configuration  audit.") 
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Carnegie  Mellon 
Software  Engineering  Institute 

New  Definitions4 

hardware  engineering 
The  application  of  a  systematic,  disciplined,  and 
quantifiable  approach  to  transform  a  set  of  requirements 
representing  the  collection  of  stakeholder  needs, 
expectations,  and  constraints  using  documented 
techniques  and  technology  to  design,  implement,  and 
maintain  a  tangible  product.  (See  also  "software 
engineering"  and  "systems  engineering.") 

In  CMMI,  hardware  engineering  represents  all  technical 
fields  (e.g.,  electrical  or  mechanical)  that  transform 
requirements  and  ideas  into  tangible  and  producible 
products  . 
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higher  level  management 
The  person  or  persons  who  provide  the  policy  and  overall 
guidance  for  the  process,  but  do  not  provide  the  direct  day- 
to-day  monitoring  and  controlling  of  the  process.  Such 
persons  belong  to  a  level  of  management  in  the 
organization  above  the  immediate  level  responsible  for  the 
process  and  can  be  (but  are  not  necessarily)  senior 
managers.  (See  also  "senior  manager.") 

physical  configuration  audit 

An  audit  conducted  to  verify  that  a  configuration  item,  as 
built,  conforms  to  the  technical  documentation  that  defines 
and  describes  it.  (See  also,  "configuration  audit," 
"configuration  management,"  and  "functional  configuration 
audit.") 
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project  startup 
When  a  set  of  interrelated  resources  are  directed  to 
develop  or  deliver  one  or  more  products  for  a  customer  or 
end  user.  (See  also  “project.”) 

service 

In  the  CMMI  Product  Suite,  a  service  is  a  product  that  is 
intangible  and  non-storable.  (See  also  "product," 
"customer,"  and  "work  product.") 


CMMI 


©  2006  by  Carnegie  Mellon  University 


CMMI  vl.2:  Model  Changes  -  081706  -  Page  36 


Carnegie  Mellon 
Software  Engineering  Institute 

Revised  Definitions1 

acquisition 

The  process  of  obtaining  products  (goods  and  services) 
through  contract. 

appraisal 

In  the  CMMI  Product  Suite,  an  examination  of  one  or  more 
processes  by  a  trained  team  of  professionals  using  an 
appraisal  reference  model  as  the  basis  for  determining,  at  a 
minimum,  strengths  and  weaknesses.  (See  also 
“assessment”  and  “capability  evaluation.”) 

appraisal  findings 

The  results  of  an  appraisal  that  identify  the  most  important 
issues,  problems,  or  opportunities  for  process  improvement 
within  the  appraisal  scope.  Appraisal  findings  are 
inferences  drawn  from  corroborated  objective  evidence. 
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appraisal  scope 
The  definition  of  the  boundaries  of  the  appraisal 
encompassing  the  organizational  limits  and  the  CMMI 
model  limits  within  which  the  processes  to  be  investigated 
operate. 

audit 

In  CMMI  process  improvement  work,  an  objective 
examination  of  a  work  product  or  set  of  work  products 
against  specific  criteria  (e.g.,  requirements). 
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capability  evaluation 
An  appraisal  by  a  trained  team  of  professionals  used  as  a 
discriminator  to  select  suppliers,  to  monitor  suppliers  against 
the  contract,  or  to  determine  and  enforce  incentives. 
Evaluations  are  used  to  gain  insight  into  the  process  capability 
of  a  supplier  organization  and  are  intended  to  help  decision 
makers  make  better  acquisition  decisions,  improve 
subcontractor  performance,  and  provide  insight  to  a 
purchasing  organization.  (See  also  “appraisal”  and 
“assessment.”) 

configuration  audit 

An  audit  conducted  to  verify  that  a  configuration  item,  or  a 
collection  of  configuration  items  that  make  up  a  baseline, 
conforms  to  a  specified  standard  or  requirement.  (See  also 
“audit,”  “configuration  item,”  "functional  configuration  audit," 
and  "physical  configuration  audit.") 
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customer 

The  party  (individual,  project,  or  organization)  responsible 
for  accepting  the  product  or  for  authorizing  payment.  The 
customer  is  external  to  the  project  (except  possibly  when 
integrated  teams  are  used,  as  in  IPPD),  but  not  necessarily 
external  to  the  organization.  The  customer  may  be  a  higher 
level  project.  Customers  are  a  subset  of  stakeholders.  (See 
also  “stakeholder.”) 

In  most  cases  where  this  term  is  used,  the  preceding 
definition  is  intended;  however,  in  some  contexts,  the  term 
"customer"  is  intended  to  include  other  relevant 
stakeholders.  (See  also  “customer  requirement.”) 
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data  management 
The  disciplined  processes  and  systems  that  plan  for, 
acquire,  and  provide  stewardship  for  business  and 
technical  data,  consistent  with  data  requirements, 
throughout  the  data  lifecycle. 

establish  and  maintain 

In  the  CMMI  Product  Suite,  you  will  encounter  goals  and 
practices  that  include  the  phrase  “establish  and  maintain.” 
This  phrase  means  more  than  a  combination  of  its 
component  terms;  it  includes  documentation  and  usage. 
For  example,  “Establish  and  maintain  an  organizational 
policy  for  planning  and  performing  the  organizational 
process  focus  process”  means  that  not  only  must  a  policy 
be  formulated,  but  it  also  must  be  documented,  and  it  must 
be  used  throughout  the  organization. 
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generic  goal 
A  required  model  component  that  describes  the 
characteristics  that  must  be  present  to  institutionalize  the 
processes  that  implement  a  process  area.  (See  also 
“institutionalization.”) 

objective  evidence 

As  used  in  CMMI  appraisal  materials,  documents  or 
interview  results  used  as  indicators  of  the  implementation 
or  institutionalization  of  model  practices.  Sources  of 
objective  evidence  can  include  instruments,  presentations, 
documents,  and  interviews. 
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process  element 
The  fundamental  unit  of  a  process.  A  process  can  be 
defined  in  terms  of  subprocesses  or  process  elements.  A 
subprocess  can  be  further  decomposed  into  subprocesses 
or  process  elements;  a  process  element  cannot.  (See  also 
"process"  and  "subprocess.") 

Each  process  element  covers  a  closely  related  set  of 
activities  (e.g.,  estimating  element  and  peer  review 
element).  Process  elements  can  be  portrayed  using 
templates  to  be  completed,  abstractions  to  be  refined,  or 
descriptions  to  be  modified  or  used.  A  process  element  can 
be  an  activity  or  task. 
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product 

In  the  CMMI  Product  Suite,  a  work  product  that  is  intended 
for  delivery  to  a  customer  or  end  user.  The  form  of  a 
product  can  vary  in  different  contexts.  (See  also  “customer,” 
"product  component,"  "service,"  and  “work  product.”) 

product  component 

In  the  CMMI  Product  Suite,  a  work  product  that  is  a  lower 
level  component  of  the  product.  Product  components  are 
integrated  to  produce  the  product.  There  may  be  multiple 
levels  of  product  components.  (See  also  “product”  and 
“work  product.”) 
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project 

In  the  CMMI  Product  Suite,  a  managed  set  of  interrelated 
resources  which  delivers  one  or  more  products  to  a 
customer  or  end  user.  A  project  has  a  definite  beginning 
(i.e.,  project  startup)  and  typically  operates  according  to  a 
plan.  Such  a  plan  is  frequently  documented  and  specifies 
what  is  to  be  delivered  or  implemented,  the  resources  and 
funds  to  be  used,  the  work  to  be  done,  and  a  schedule  for 
doing  the  work.  A  project  can  be  composed  of  projects. 
(See  also  “project  startup.”) 
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quality  and  process-performance  objectives 
Objectives  and  requirements  for  product  quality,  service 
quality,  and  process  performance.  Process-performance 
objectives  include  quality;  however,  to  emphasize  the 
importance  of  quality  in  the  CMMI  Product  Suite,  the  phrase 
quality  and  process-performance  objectives  is  used  rather 
than  just  process-performance  objectives. 

requirements  traceability 

A  discernable  association  between  requirements  and 
related  requirements,  implementations,  and  verifications. 
(See  also  "bidirectional  traceability"  and  "traceability.") 
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shared  vision 

A  common  understanding  of  guiding  principles  including 
mission,  objectives,  expected  behavior,  values,  and  final 
outcomes,  which  are  developed  and  used  by  a  project. 

subprocess 

A  process  that  is  part  of  a  larger  process.  A  subprocess  can 
be  decomposed  into  subprocesses  and/or  process 
elements.  (See  also  “process,"  "process  description,”  and 
"process  element.") 

traceability 

A  discernable  association  among  two  or  more  logical 
entities  such  as  requirements,  system  elements, 
verifications,  or  tasks.  (See  also  "bidirectional  traceability" 
and  “requirements  traceability.”) 
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work  product 

In  the  CMMI  Product  Suite,  a  useful  result  of  a  process. 

This  can  include  files,  documents,  products,  parts  of  a 
product,  services,  process  descriptions,  specifications,  and 
invoices.  A  key  distinction  between  a  work  product  and  a 
product  component  is  that  a  work  product  is  not  necessarily 
part  of  the  product.  (See  also  “product”  and  “product 
component.”) 

In  CMMI  models,  you  will  see  the  phrase  work  products  and 
services.  Even  though  the  definition  of  work  product 
includes  services,  this  phrase  is  used  to  emphasize  the 
inclusion  of  services  in  the  discussion. 
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Improvements  were  made  to  all  process  areas;  some 
process  areas  changed  more  than  others.  Only  the  process 
areas  that  were  changed  significantly  will  be  addressed. 

Many  of  these  changes  were  discussed  earlier.  However, 
these  slides  show  you  significant  changes  by  process  area. 
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The  following  process  areas  were  improved  significantly: 

•  Integrated  Project  Management  +IPPD  (IPM+IPPD) 

•  Organizational  Process  Definition  +IPPD  (OPD+IPPD) 

•  Organizational  Process  Focus  (OPF) 

•  Requirements  Management  (REQM) 

•  Requirements  Development  (RD) 

•  Supplier  Agreement  Management  (SAM) 

•  Technical  Solution  (TS) 

•  Validation  (VAL) 

•  Verification  (VER) 
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Specific  Goal  Specific  Practice 

Use  the  Project’s  1.1  -  Establish  the  Project’s  Defined 

Defined  Process  Process 

1.2  -  Use  Organizational  Process  Assets 

for  Planning  Project  Activities 

1.3  -  Establish  the  Project’s  Work 

Environment 

1.4  -  Integrate  Plans 

1.5-  Manage  the  Project  Using  the 
Integrated  Plans 

1.6-  Contribute  to  the  Organizational 
Process  Assets 


CMMI 


•  Modified  SP  1.1  from  “Establish  and  maintain  the  project’s  defined 
process”  to  “Establish  and  maintain  the  project’s  defined  process  from 
project  startup  through  the  life  of  the  project.” 


Added  SP  1.3  “Establish  the  Project’s  Work  Environment.”  (This  practice 
is  new  to  CMMI.) 
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Specific  Goal_ Specific  Practice 

Coordinate  and  2.1  -  Manage  Stakeholder  Involvement 

Collaborate  with  2.2  -  Manage  Dependencies 

Relevant  Stakeholders  2.3  -  Resolve  Coordination  Issues 

Apply  IPPD  Principles  3.1  -  Establish  the  Project’s  Shared 

Vision 

3.2  -  Establish  the  Integrated  Team 

Structure 

3.3  -  Allocate  Requirements  to 

Integrated  Teams 

3.4  -  Establish  Integrated  Teams 

3.5  -  Ensure  Collaboration  among 

Interfacing  Teams 

•  Reduced  the  IPPD  Addition  to  one  goal  (SG3  “Apply  IPPD  Principles”) 
and  its  practices. 

•  To  emphasize  the  IPPD  Addition,  the  name  of  this  process  area  is  now 
“Integrated  Project  Management  +IPPD”  or  “IPM  +IPPD.” 
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Organizational  Process  Definition 
+IPPD1 

Specific  Goal  Specific  Practice 


Establish  Organizational 
Process  Assets 


1.1  -  Establish  Standard  Processes 

1.2  -  Establish  Lifecycle  Model 

Descriptions 

1.3  -  Establish  Tailoring  Criteria  and 

Guidelines 


1.4  -  Establish  the  Organization’s 

Measurement  Repository 

1.5  -  Establish  the  Organization’s  Process 

Asset  Library 

1.6  -  Establish  Work  Environment 

Standards 


•  Added  “and  work  environment  standards”  to  the  purpose  statement. 

•Added  SP  1.6  “Establish  Work  Environment  Standards.”  (This  practice 
is  new  to  CMMI.) 
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Specific  Goal _ Specific  Practice _ 

Enable  IPPD  Management  2.1  -  Establish  Empowerment 

Mechanisms 

2.2  -  Establish  Rules  and  Guidelines  for 

Integrated  Teams 

2.3  -  Balance  Team  and  Home 

Organization  Responsibilities 


CMMI 


•  Added  an  IPPD  Addition  to  OPD  (SG2  “Enable  IPPD  Management”  and 
its  practices). 

•  To  emphasize  the  IPPD  Addition,  the  name  the  process  area  is  now 
“Organizational  Process  Definition  +IPPD”  or  “OPD  +IPPD.” 
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Specific  Goal 

Specific  Practice 

Determine  Process 

Improvement 

Opportunities 

1.1  -  Establish  Organizational  Process 
Needs 

1.2-  Appraise  the  Organization’s 
Processes 

1.3-  Identify  the  Organization’s 

Process  Improvements 

•  Modified  the  purpose  statement  to  emphasize  deployment. 

•  SP  1.2  “Appraise  the  organization’s  processes  periodically  and  as 
needed  to  maintain  an  understanding  of  their  strengths  and 
weaknesses.”  uses  “organization’s  processes”  instead  of  “processes  of 
the  organization.” 
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Specific  Goal 

Specific  Practice 

Plan  and  Implement 
Process 

Improvements 

2.1  -  Establish  Process  Action  Plans 

2.2  -  Implement  Process  Action  Plans 

•  Modified  SG2  from  “Plan  and  Implement  Process  Improvement 
Activities”  to  “Plan  and  Implement  Process  Improvements.” 

•  Moved  to  a  new  SG3  and  modified  what  were  SP  2.3  and  SP  2.4  in 
vl.1. 
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Specific  Goal 

Specific  Practice 

Deploy  Organizational 
Process  Assets  and 
Incorporate  Lessons 
Learned 

3.1  -  Deploy  Organizational  Process 

Assets 

3.2  -  Deploy  Standard  Processes 

3.3  -  Monitor  Implementation 

3.4  -  Incorporate  Process-Related 

Experiences  into  the 

Organizational  Process  Assets 

•Added  new  SG3,  “Deploy  Organizational  Process  Assets  and 
Incorporate  Lessons  Learned.” 

•  Moved  what  were  SP  2.3  and  SP  2.4  in  vl  .1  to  the  new  SG3  as  SP  3.1 
and  SP  3.4. 

•  Added  two  new  SPs:  SP  3.2  “Deploy  Standard  Processes,”  and  SP  3.3 
“Monitor  Implementation.” 
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Specific  Goal 

Specific  Practice 

Manage  Requirements 

1.1  -  Obtain  an  Understanding  of 
Requirements 

1.2-  Obtain  Commitment  to 

Requirements 

1.3  -  Manage  Requirements  Changes 

1.4-  Maintain  Bidirectional 

Traceability  of  Requirements 

1.5  -  Identify  Inconsistencies  Between 
Project  Work  and  Requirements 

•VI. 2  REQM  SP  1.4  practice  statement  now  reads,  “Maintain 
bidirectional  traceability  among  the  requirements  and  work  products.” 

•  Project  plans  are  no  longer  mentioned  in  this  SP  statement. 

•  The  description  of  bidirectional  traceability  is  improved  as  is  its 
definition  in  the  glossary. 
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Requirements  Development1 


Specific  Goal 

Specific  Practice 

Develop  Customer 
Requirements 

1.1  -  Elicit  Needs 

1.2-  Develop  the  Customer 

Requirements 

Develop  Product 
Requirements 

2.1  -  Establish  Product  and  Product 

Component  Requirements 

2.2  -  Allocate  Product  Component 

Requirements 

2.3  -  Identify  Interface  Requirements 

•  Former  base  practice  “Collect  Stakeholder  Needs”  is  eliminated  and 
former  advanced  practice,  “Elicit  Needs”  is  kept. 

•  Informative  text  is  added  to  the  introductory  notes  about  applying  RD 
to  maintenance  projects. 
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Requirements  Development2 


Specific  Goal 

Specific  Practice 

Analyze  and  Validate 
Requirements 

3.1  -  Establish  Operational  Concepts 

and  Scenarios 

3.2  -  Establish  a  Definition  of  Required 

Functionality 

3.3  -  Analyze  Requirements 

3.4  -  Analyze  Requirements  to  Achieve 

Balance 

3.5  -  Validate  Requirements 

•  Material  from  VI. 1  TS  SP  1.2,  “Evolve  Operational  Concepts  and 
Scenarios,”  is  incorporated  into  RD  SP  3.1. 

•  Material  from  VI. 1  RD  SP  3.5-1,  “Validate  Requirements,”  and  RD 
SP  3.5-2,  “Validate  Requirements  with  Comprehensive  Methods” 
were  consolidated  into  a  single  practice. 
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Specific  Goal  Specific  Practice 


Establish  Supplier 
Agreements 

1.1  -  Determine  Acquisition  Type 

1.2-  Select  Suppliers 

1.3  -  Establish  Supplier  Agreements 

Satisfy  Supplier 
Agreements 

2.1  -  Execute  the  Supplier  Agreement 

2.2  -  Monitor  Selected  Supplier 

Processes 

2.3  -  Evaluate  Selected  Supplier  Work 

Products 

2.4  -  Accept  the  Acquired  Product 

2.5  -  Transition  Products 

•  VI. 1  SAM  SP2.1  “Review  COTS  Products,”  was  eliminated.  “Identify 
candidate  COTS  products  that  satisfy  requirements”  is  a  new 
subpractice  under  the  Technical  Solutions  Process  Area  SP1 .1 , 
“Develop  Alternative  Solutions  and  Selection  Criteria.” 

•  SP2.2  and  SP2.3  were  added  because  ISM  was  eliminated. 

•  The  purpose  of  SAM  was  also  updated. 
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Carnegie  Mellon 

Software  Engineering  Institute  CMML 

Technical  Solution1 


Specific  Goal 

Specific  Practice 

Select  Product- 
Component  Solutions 

1.1  -  Develop  Alternative  Solutions  and 

Selection  Criteria 

1.2  -  Select  Product-Component 

Solutions 

•  VI. 1  TS  SP  1.1-1,  “Develop  Alternative  Solutions  and  Selection 
Criteria,”  and  TS  SP  1.1-2,  “Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria”  are  consolidated  into  a  single  practice. 

•  “Identify  candidate  COTS  products  that  satisfy  requirements”  is  a  new 
subpractice  under  SP1.1. 

•  VI. 1  TS  SP  1.2  “Evolve  Operational  Concepts  and  Scenarios”  is 
incorporated  into  RD  SP  3.1,  “Establish  Operational  Concepts  and 
Scenarios.” 
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Carnegie  Mellon 

Software  Engineering  Institute  CMML 

Technical  Solution2 


Specific  Goal 

Specific  Practice 

Develop  the  Design 

2.1  -  Design  the  Product  or  Product 

Component 

2.2  -  Establish  a  Technical  Data 

Package 

2.3  -  Design  Interfaces  Using  Criteria 

2.4  -  Perform  Make,  Buy,  or  Reuse 

Analyses 

Implement  the 

Product  Design 

3.1  -  Implement  the  Design 

3.2  -  Develop  Product  Support 

Documentation 

•  VI  .1  TS  SP  2.3-1 ,  “Establish  Interface  Descriptions,”  and  TS  SP  2.3- 
3,  “Design  Interfaces  Using  Criteria”  are  consolidated  into  a  single 
practice. 
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Software  Engineering  Institute  CMML 

Validation 


Specific  Goal 

Specific  Practice 

Prepare  for  Validation 

1.1-  Select  Products  for  Validation 

1.2  -  Establish  the  Validation 

Environment 

1.3  -  Establish  Validation  Procedures 

and  Criteria 

Validate  Product  or 
Product  Components 

2.1  -  Perform  Validation 

2.2  -  Analyze  Validation  Results 

•  Notes  were  added  to  VAL  to  stress  that  validation  activities  are 
performed  incrementally  and  involve  relevant  stakeholders. 

•  The  phrase  “and  identify  issues”  was  deleted  from  the  statement  of  SP 

2.2  “Analyze  Validation  Results”  to  maintain  parallelism  with  VER  SP 

3.2  “Analyze  Verification  Results.” 
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Carnegie  Mellon 

Software  Engineering  Institute  CMML 

Verification1 


Specific  Goal 

Specific  Practice 

Prepare  for  Verification 

1.1-  Select  Work  Products  for 
Verification 

1.2  -  Establish  the  Verification 

Environment 

1.3  -  Establish  Verification  Procedures 

and  Criteria 

Perform  Peer  Reviews 

2.1  -  Prepare  for  Peer  Reviews 

2.2  -  Conduct  Peer  Reviews 

2.3  -  Analyze  Peer  Review  Data 

•  No  changes  to  SGI ,  SG2,  or  their  practices 
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Carnegie  Mellon 

Software  Engineering  Institute  CMML 

Verification2 


Specific  Goal 

Specific  Practice 

Verify  Selected  Work 
Products 

3.1  -  Perform  Verification 

3.2  -  Analyze  Verification  Results 

•  The  phrase  “and  identify  corrective  action”  was  deleted  from  both 
the  title  and  statement  of  SP  3.2  “Analyze  Verification  Results. 
(Corrective  action  is  handled  in  PMC  SG2,  “Manage  Corrective 
Action  to  Closure.) 
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Software  Engineering  Institute 

Summary 

Many  changes  were  made  to  the  CMMI  models  to  improve 
quality.  The  major  changes  include 

•  name  changed  to  “CMMI  for  Development” 

•  both  representations  in  one  document 

•  amplifications  improved;  added  hardware  amplifications 

•  common  features  and  advanced  practices  eliminated 

•  SS  addition  eliminated;  ISM  brought  into  SAM 

•  guidelines  for  “not  applicable”  process  areas  clarified 

•  overview  and  glossary  improved 

•  work  environment  material  added  to  OPD  and  IPM 

•  IPPD  material  simplified  and  consolidated 

•  process  deployment  strengthened  in  IPM  and  OPF 


CMMI. 
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